Remarks 



1. 35 U.S.C. §112 

The Office Action rejects claims 1-12, 14-25, 27-32, 41, 46, 53 and 57 under 35 
U.S.C. §112, second paragraph, as allegedly being indefinite for failing to particularly 
point out and distinctly claim the subject matter which applicant regards as the invention. 

A. Claims 1.24 and 53 

Regarding claims 1, 24 and 53, the Office Action states: 

Claims 1, 24, 53 recites the limitation, "associating an operation 
code with said first packet, wherein said operation code indicates a status 
of said first packet, including whether said packet is to be transferred to 
the host computer system for processing in accordance with said pres- 
selected protocol". Claim 1 then recites, "transferring said first packet to 
the host computer system for processing in accordance with said 
preselected protocol." It is unclear what the purpose is of determining 
whether to transfer the packet to this host is for, when the next limitation 
always transfers the packet. It appears to defeat the entire purpose of the 
"determining step" when the following limitation always transfers the 
packet. 

Claim 1 has been amended to recite, in part, "wherein said operation code 
indicates a status of said first packet, including whether said packet is a candidate for 
transfer to the host computer system that avoids processing in accordance with said pre- 
selected protocol." Applicants respectfijlly assert that this overcomes the issue identified 
by the Final Rejection. Claims 24 and 53 have been similarly amended. 

B. Claim 24 

Regarding claim 24, the Office Action states: 

Claim 24 as amended recites, "A method of transferring a packet to 
a host computer ". The last limitation of claim 24 recites, "transferring said 
first packet to a host computer", which appears to include insufficient 
antecedent basis. It is imclear as to whetiier this refers to the same host 
computer recited in the preamble, or another host computer. 

Claim 24 has been amended to recite, in part, "transferring said first packet to the 
host computer system." 
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c. 



Claims 24 and 25 



Regarding claims 24 and 25, the Office Action states: 

Claim 25 recites, "The method of claim 24, further comprising: 
transferring said TCB from said host computer system to said 
communication device." However, it appears in claim 24 that the TCB is 
generated at the communication device. 

Claim 24 

The first limitation recites, "parsing a header portion of a first 
packet received at a communication device to determine if said first packet 
conforms to a pre-selected protocol". This limitation clearly recites the 
parsing being performed at the communication device. 

The second limitation recites, "generating a TCP control block 
(TCB) to identify a first communication flow that includes said first 
packet". This limitation clearly requires the possession of the packet in 
order to generate tiie TCB to identify the flow that includes said first 
packet . 

The third limitation recites, "associating a summary with said first 
packet, wherein said summary indicates a status of said first packet, 
including whether said packet is to be transferred to the host computer 
system for processing". This limitation clearly shows that the packet has 
not yet been transferred to the host computer system, but rather indicates 
whether the packet should or should not be transferred to the host 
computer system. Therefore, the second limitation, (i.e. generating a TCB 
that identifies a flow including said first packet) must be performed at the 
communication device since the generation step clearly requires the use of 
the first packet, and the packet has not even been transferred to the host 
device at this point. 

However, claim 25 recites, "The method of claim 24, further 
comprising: transferring said TCB firom said host computer system to said 
communication device. " Therefore it is unclear how the TCB is transferred 
from the host computer system to the commimication device if such is 
generated at the communication device. 

Applicants respectfully note that while claim 24 recites, in part, "generating a 
TCP control block (TCB) to identify a first communication flow that includes said first 
packet," it does not recite that the TCP is generated by "the communication device." For 
example, the TCB could be generated by the "the communication device" or by "host 
computer system." In the latter case, the TCB could be transferred to "the 
communication device" or be accessible by "the communication device." Thus, 
applicants respectfully assert claim that 24 is not indefinite. 
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Applicants have amended claim 25 recite, in part, "wherein said generating a TCP 
control block (TCB) is performed by said host computer system, and further comprising: 
transferring said TCB from said host computer system to said communication device." 
Thus, applicants respectftiUy assert that claim 25 is not indefinite. 

D. Claim 32 

Regarding claim 32, the Office Action states: 

Claim 32 recites, "A method of transferring a packet received at a 
network interface to a host computer system". The amended limitation 
recites, "if the host computer system contains a plurality of processors 
such that a first of the processors is on the network interface". The 
preamble differentiates the network interface and the host computer 
system as two separate elements. Therefore it is unclear how one of the 
host computer system's processors can be on the network interface. 

Claim 3 has been amended to recite, m part, "A method of transferring a packet 
received at a network interface of a host computer system." Thus, applicants respectfully 
assert that claim 32 is not indefinite. 



II. 35 U.S.C. $103 

Claims 1-12, 14-17, 20-31, 42-44, 46-53 and 55-56 stand rejected under 35 
U.S.C. 103(a) as allegedly being unpatentable over U.S. PatentNo. 6,172,980 to Flanders 
et al. ("Flanders"). 

A. Claims 1.24 and 53 

Regarding claims 1, 24 and 53, the Office Action states: 

Regarding claims 1, 24, 53, Flanders disclosed a method of 
transferring a packet to a computer system, wherein the packet is received 
at a communication device from a network (Flanders, col. 1, lines 39-41, a 
network router receiving and routing packets), comprising: 

parsing a header portion of a first packet received at a 
communication device to determine if said first packet conforms to a pre- 
selected protocol (Flanders, col. 3, lines 60-65, "RHP (Receive Header 
Processor) determines the protocol being used for the received data unit"; 
See also col. 6, lines 50-51); 

generating a flow key to identify a first communication flow that 
includes said first packet (Flanders, col. 6, line 50 through col. 7, line 5, 
port information extracted fi-om the received fi-ame in order to classify 
packet according to flow ID, tiie information extracted from the packet 
used as a flow key to look the packet up); 
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routing the packets to their destination (Flanders, col. 1, lines 50- 
55, Flanders disclosed the router making forwarding decisions to route the 
packet, see also Abstract, "identifying a data unit to be routed by a router) 

associating an operation code with said first packet, wherein said 
operation code indicates a status of said first packet (Flanders, col. 6, line 
65 through col. 7, line 15, in accordance with the received frame, a status 
word is set; see also, col. 4, lines 15-23). 

Flanders further disclosed forwarding the packets for receipt by a 
downstream network device (Flanders, col. 9, lines 40-43). 

Flanders did not explicitly state transferring said first packet to the 
disclosed device system for processing in accordance with said pre- 
selected protocol. 

However, it would have been obvious to one of ordinary skill in 
the art at the time the invention was made that since the router of Flanders 
clearly routes the packet to a network device, that the network device must 
perform the proper protocol processing on the packet in order to properly 
interpret the information fi-om that packet. For example, using the very 
well known TCP/IP protocol, in order for two computers to successfiilly 
communicate via TCP/IP (Flanders, Fig. 6), both computers must protocol 
process the TCP/IP packets, which are clearly routed through the Internet, 
via routers such as the one described by Flanders. 

Therefore, it would have been obvious to one of ordinary skill in 
the art at the time the invention was made to interpret the routing of a 
packet to its destination to include that destination performing the proper 
protocol processing in order to obtain the predictable result of the 
destination device being able to successfully interpret that packet at the 
receiving end, thereby resulting in successful communication. 

Claim 24 includes a method with limitations that are substantially 
similar to the limitations of claim 1, and is therefore rejected under the 
same rationale. Claim 53 recites a computer readable storage medium 
storing instructions tiiat perform the method of claim 1. Therefore claims 
24, 53 are rejected under the same rationale. 

Applicants have amended claim 1 to recite, in part, "parsing a header portion of a 
first packet received at a network interface for the host computer." Flanders, on the other 
hand, teaches "a network bridge/router for identifying received data units which may 
require routing, for identifying a protocol associated witii the received data unit, for 
determining whether the received data unit is in fact to be bridged or routed, and for 
carrying out appropriate data unit transfer operations, all in hardware." Column 1, lines 
39-44. In other words, Flanders teaches forwarding packets by its communication device 
rather than processing packets at a network interface for the host computer. 
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Moreover, claim 1 has also been amended to recite "wherein said operation code 
indicates a status of said first packet, including whether said packet is a candidate for 
transfer to the host computer system that avoids processing in accordance with said pre- 
selected protocol." The invention of Flanders is directed to hardware that determines 
whether packets are bridged or routed, and does not disclose this recitation. 

Claims 24 and 53 have been amended in a manner similar to claim 1 . For the 
foregoing reasons, applicants respectfully assert that claims 1, 24 and 53, and any claims 
that depend from claims 1, 24 and 53 are not obvious over Flanders. 



B. Claims 42 and 44 

Regarding claims 42 and 44, the Office Action states: 

Regarding claims 42 and 44, Claim 42 includes an apparatus with a 
memory and modules to perform the limitations that are substantially 
similar to claim 1 and claim 44 recites a computer system with limitations 
that are substantially to claims 1. Claims 42 and 44 fijrther includes a 
"flow re-assembler configured to re-assemble a data portion of said first 
packet with a data portion of second packet in said communication flow 
and storing both packets in memory as well as a processor to process said 
packet. As shown in the rejection of claim 1, Flanders disclosed a router 
performing these limitations. 

Flanders did not explicitly state flow re-assembler configured to 
re-assemble a data portion of said first packet with a data portion of 
second packet in said communication flow and storing both packets in 
memory of the downstream network device. 

However, it would have been obvious to one of ordinary skill in 
the art at the time the invention was made that since the router of Flanders 
clearly routes the packets belonging to a particular flow to a network 
device, that the network device must perform the proper protocol 
processing on the packets in order to properly interpret the information 
firom that packet, thereby requiring storing of the packet data and 
combining the data to properly interpret the flow. For example, using the 
very well known TCP/IP protocol, in order for two computers to 
successfully communicate via TCP/IP (Flanders, Fig. 6), both computers 
must protocol process the TCP/IP packets, which are clearly routed 
throu^ the Internet, via routers such as the one described by Flanders. 

Therefore, it would have been obvious to one of ordinary skill in 
the art at the time the invention was made to interpret the routing of a 
packets to their destination to include that destination actually storing the 
packet data in order to perform the proper protocol processing in order to 
obtain the predictable result of the destination device being able to 
successfully interpret/batch that data fi-om the packets at the receiving end, 
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thereby resulting in successful communication. For example, the routing 
of a file that requires multiple packets to be sent in order to transmit the 
entire file across the network, which requires the receiving end to properly 
protocol process the packets that make up the file and re-assemble the data 
portions in order for communication of the file to properly occur. 

Claim 42 has been amended to recite, in part, "a traffic classifier, disposed in a 
network interface for the host computer system." Claim 42 has also been amended to 
recite that a packet memory, a packet batching module and a flow re-assembler are all 
"disposed in the network interface." As noted above, the "network bridge/router" of 
Flanders is directed to forwarding fi-ames "for receipt by a downstream network device," 
rather than "a network interface for the host computer system." For at least this reason, 
applicants respectfully assert that claim 42 is not obvious over Flanders. 

In addition, applicants have amended claim 42 to recite "said first packet data 
portion and said second packet data portion are stored in a host computer memory area 
that is controlled by a host computer application." Nothing in Flanders teaches or 
suggests this recitation. For at least this additional reason, applicants respectfully assert 
that claim 42 and any claims that depend fi"om claim 42 are not obvious over Flanders. 

Similarly, claim 44 has been amended to recite a "network interface for the 
computer system." As noted above, the "network bridge/router" of Flanders is directed 
to forwarding frames "for receipt by a downstream network device," rather than "a 
network interface for the computer system." For at least this reason, applicants 
respectfully assert that claim 44 is not obvious over Flanders. 

Claim 44 was previously amended to recite in part "a re-assembler for storing 
data portions of said multiple packets without header portions in a first portion of said 
memory." The Final Rejection, however, does not discuss this recitation. Applicants 
respectfully reiterate that Flanders does not teach "a re-assembler for storing data 
portions of said multiple packets without header portions m a first portion of said 
memory." Moreover, applicants assert that it would not have been obvious to modify 
Flanders to create "a re-assembler for storing data portions of said multiple packets 
without header portions in a first portion of said memory." Because the frames of 
Flanders are forwarded, and because networks such as Ethernet networks typically have 
rules limiting frame sizes, "storing data portions of said multiple packets without header 
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portions" would likely cause the frames to be too large to forward, thwarting the primary 
purpose of Flanders, as well as delaying any forwarding that actually occurred, without 
any discemable benefit. For at least this reason, applicants respectfully assert that claim 
44 is not obvious over Flanders. 



C. Claim 47 

Regarding claim 47, the OfBce Action states: 

Regarding claim 47, Flanders disclosed a device for receiving a 
packet from a network and transferring the packet to a host computer 
system, comprising: 

a parser configured to parse a header portion of a packet received 
from a network, wherein said parsing comprises: determining whether a 
header within said header portion conforms to one of a set of 
communication protocols (Flanders, col. 3, lines 60-65, "RHP (Receive 
Header Processor) determines the protocol being used for the received 
data unit"; See also col. 6, lines 50-51); and 

if said header conforms to one of said communication protocols, 
extracting information from said header portion to identify a 
commimication flow to which said packet belongs (Flanders, col. 6, line 
50 through col. 7, line 5, port information extracted from the received 
frame in order to classify packet according to flow ID, the information 
extracted from the packet used as a flow key to look the packet up); a flow 
memory configured to store a flow identifier for identifying said 
communication flow; a flow manager configured to assign an operation 
code to said packet, wherein said operation code: indicates a status of said 
packet; and indicates a manner of transferring said packet to the host 
computer system; a packet memory configured to store said packet 
(Flanders, col. 6, line 65 through col. 7, line 15, in accordance with the 
received frame, a status word is set; see also, col. 4, lines 15-23. Flanders 
fiirther disclosed forwarding the packets for receipt by a downstream 
network device (Flanders, col. 9, lines 40-43). 

Flanders did not expUcitly state transferring said first packet to the 
disclosed device system for processing in accordance with said pre- 
selected protocol. 

However, it would have been obvious to one of ordinary skill in 
the art at the time the invention was made that since the router of Flanders 
clearly routes the packet to a network device, that the network device must 
perform the proper protocol processing on the packet in order to properly 
interpret the information from that packet. For example, using the very 
well known TCP/IP protocol, in order for two computers to successfully 
communicate via TCP/IP (Flanders, Fig. 6), both computers must protocol 
process the TCP/IP packets, which are clearly routed through the Intemet, 
via routers such as the one described by Flanders. 
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Therefore, it would have been obvious to one of ordinary skill in 
the art at the time the invention was made to interpret the routing of a 
packet to its destination to include that destination performing the proper 
protocol processing in order to obtain the predictable result of the 
destination device being able to successfully interpret that packet at the 
receiving end, thereby resulting in successful communication. 

Flanders also did not explicitly state wherein said device is coupled 
to the host computer system by a bus. However it well known to one of 
ordinary skill that a bus is a device that is used to connect various 
computers/devices in a network. Since the router and end node is 
connected by a network, it would have been obvious to one of ordinary 
skill in the art at the time the invention was made to couple these devices 
via a bus thereby making the system scalable towards already well known 
devices. 

Claim 47 has been amended to recite in part "wherein said device is a peripheral 
device for the host computer system." Applicants respectfiilly assert that Flanders does 
not teach or suggest "wherein said device is a peripheral device for the host computer 
system." Instead, Flanders states in column 9, lines 41-43: "Outbound frames are 
forwarded from the TXSM FffO 64 over the respective output port 20 of the network 
interface module 14 for receipt by a downstream network device." For at least this 
reason, applicants respectfully assert that claim 47 and all the claims that depend from 
claim 47 are not obvious over Flanders. 



D. Claims 32. 45 and 54 

Claims 32, 45 and 54 stand rejected under 35 U.S.C. 103(a) as allegedly bemg 

unpatentable over Flanders in view of U.S. Patent No. 5,590,328 to Seno et al. ("Seno"). 

Regarding claim 32, the Office Action states: 

Regarding claim 32, Flanders disclosed a method of transferring a 
packet received at a network interface to a host computer system, 
comprising: 

receiving a packet from a network, storing said packet in a packet 
memory and parsing a header portion of said packet; extracting a value 
stored m said header portion; identifying a communication flow 
comprising said packet (Flanders, col. 3, lines 60-65, "RHP (Receive 
Header Processor) determines the protocol being used for the received 
data unit"; See also col. 6, lines 50-51; col. 6, line 50 through col. 7, line 5, 
port information extracted from the received frame in order to classify 
packet according to flow ED, the information extracted from the packet 
used as a flow key to look the packet up); 



Request for Reconsideration 
App. No: 10/601,237 



23 



determining whether a header in said header portion conforms to a 
pre-selected protocol (Flanders, col. 3, lines 60-65, "RHP (Receive Header 
Processor) determines the protocol being used for the received data unit"); 

determining whether a second packet in said packet memory is part 
of said communication flow (Flanders, col. 1, lines 39-40, Flanders 
disclosed performing the same for multiple received data units); and 

if the host computer system contains a plurality of processors such 
that a first processor of the processors is on the network interface and a 
second of the processors is on the host computer, identifying a processor 
of the first and second processors to process said packet (Flanders, col. 4, 
luies 22-35, 50-63 Flanders disclosed tiie RHP determining whether the 
packet is to be routed or bridged and performing protocol processing on 
the packet when it is to be routed based on bytes, therefore determining 
whether the interface processes the packet or if it is sent to the end device 
for processing). Flanders further disclosed forwarding the packets for 
receipt by a downstream network device (Flanders, col. 9, lines 40-43) 

Flanders further disclosed forwarding the packets for receipt by a 
downstream network device (Flanders, col. 9, lines 40-43) 

Flanders did not explicitly state the step of storing said packet in a 
host memory area in the downstream network device. 

However, it would have been obvious to one of ordinary skill in 
the art at the time the invention was made that since the router of Flanders 
clearly routes the packet to a network device, that the network device must 
perform the proper protocol processing on the packet in order to properly 
interpret the mformation from that packet, thereby requiring storing of the 
packet. For example, using the very well known TCP/IP protocol, in order 
for two computers to successfully communicate via TCP/IP (Flanders, Fig. 
6), both computers must protocol process the TCP/IP packets, which are 
clearly routed through the Internet, via routers such as the one described 
by Flanders. 

Therefore, it would have been obvious to one of ordinary skill in 
the art at the time the invention was made to interpret the routing of a 
packet to its destination to include that destination actually storing the 
packet in order to perform the proper protocol processing in order to 
obtain the predictable result of the destination device being able to 
successfully interpret that packet at the receiving end, thereby resulting in 
successful communication. 

Claim 32 has been amended to recite, in part, "receiving, by the network 
interface, a packet from a network; storing, by the network interface, said packet in a 
packet memory; parsing, by the network interface, a header portion of said packet; 
extracting, by the network interface, a value stored in said header portion; identifying, by 
the network interface, a communication flow comprising said packet; determining, by the 
network interface, whether a header in said header portion conforms to a pre-selected 
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protocol; determining, by Hie network interface, whether a second packet in said packet 
inemory is part of said communication flow; and storing, by the network interface, said 
packet in a host memory area.." Applicants respectfially assert that neither Seno nor 
Flanders teaches or suggests these recitations, and that claim 32 is nonobvious over 
Flanders in view of Seno. 

Claims 45 and 54 depend from independent claims 42 and 47, respectively, and 
are nonobvious for the reasons discussed with regard to those independent claims. 

III. Allowable Subject Matter 

The Final Rejection states that claims 13, 33-40 and 58-62 are allowed, and that 
claims 19, 41, 57 are objected to as being dependent upon a rejected base claim, but 
would be allowable if rewritten in independent form including all of the limitations of the 
base claim and any intervening claims. Applicants appreciate the Examiners indication 
of patentable subject matter. As discussed above, however, applicants respectfully assert 
that all of the pending claims are patentable, in light of the amendments to the claims. 

rV. Conclusion 

Applicants appreciate the time spent by the Examiner for his thorough 
examination of this large set of claims as well as his review of this reply. Applicants 
believe that the claims are now allowable and solicit a Notice of Allowance. Should the 
Examiner have any questions about this reply or application he is respectfully requested 
to telephone the undersigned. 

Respectfully submitted, 

/Mark Lauer/ 

Mark Lauer 

Reg. No. 36,578 

Silicon Edge Law Group LLP 

6601 Koll Center Parkway 

Suite 245 

Pleasanton, CA 94566 
Tel: (925) 621-2121 
Fax: (925) 621-2125 
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